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ABSTRACT 


The  paperless  ship  conc^t  proposed  by  VADM  Metcalf  has  been  advocated 
at  the  highest  levels  in  the  Navy.  ARGOS  is  a  prototype  multi-media  database 
system  under  development  at  the  Naval  Postgraduate  School  in  support  of  this 
superior  concept.  This  thesis  has  implemented  a  tactical  evaluation  and  assistance 
tool  called  Threat  Evaluator  that  can  be  used  as  an  additional  module  to  the 
ARGOS  system  or  as  a  stand  alone  application.  Threat  Evaluator  automates 
many  of  the  evaluation  and  information  keeping  duties  that  a  Tactical  Action 
Officer  is  required  to  perform  during  normal  watchstanding  evolutions.  It 
demonstrates  the  advanced  capabilities  attainable  in  a  system  implemented  with 
economical,  off-the-shelf  technology. 
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I.  INTRODUCTION 

In  the  United  States  Navy  there  are  several  watch  stations  that  require  a 
substantial  investment  in  both  time  and  energy  to  not  only  develop  the  skills  and 
knowledge  base,  but  also  to  earn  the  confidence  and  trust  of  the  Commanding 
Officer  (CO).  One  of  the  most  critical  positions  is  that  of  Tactical  Action 
Officer  (TAO).  The  TAO  has  the  authority  to  engage  the  enemy  and  release 
weapons  in  the  absence  of  the  CO.  The  Navy  organization  manual  [Ref.l]  states 
the  following  duties  of  the  TAO: 

a.  Basic  Function.  When  assigned,  the  Tactical  Action  Officer 
is  the  commanding  officer’s  representative  concerning  the  tactical 
employment  and  the  defense  of  the  unit. 

b.  Duties,  Responsibilities,  and  Authority.  The  TAO  is 
responsible  for  the  safe  and  effective  operation  of  the  combat 
systems  and  for  any  other  duties  prescribed  by  the  commanding 
officer.  Circumstances  permitting,  the  TAO  shall  carry  out 
promptly  and  precisely  special  orders  and  shall  report  deviations  to 
the  commanding  officer. 

Currently,  much  of  the  data  required  by  a  TAO  is  contained  in  publications 
that  must  be  manually  assimilated.  This  can  take  an  inordinate  amount  of  time  to 
find  critical  information.  Manual  data  retrieval  methods  typically  increase  the 
probability  of  selecting  incorrect  data  which,  in  turn,  results  in  an  erroneous 
evaluation.  Other  information  required  by  a  TAO  is  contained  on  turnover 
sheets  and  written  on  status  boards.  Many  times  this  information  is  not  kept 
current  or  may  be  forgotten  altogether.  This  can  result  in  critical  and/or 
perishable  information  being  lost  during  the  normal  watch  to  watch  turnover. 
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These  problems  can  be  solved  with  development  of  an  application  that  would 
greatly  assist  TAO’s  in  their  duties  by  automating  the  myriad  functions  that  a 
TAO  must  accomplish  in  his  or  her  normal  watch  duties.  These  would  include 
the  searching  of  data  to  match  an  emitter  with  a  platform  or  having  available  the 
current  status  of  all  ships’  weapons  and  engineering  systems.  This  application. 
Threat  Evaluator,  would  be  developed  in  accordance  with  the  Argos  architecture 
[Ref.  2].  This  architecture  specifies  a  multi-media  interface  that  provides  access 
to  a  real  time  database.  This  application  interface  would  support  text,  graphics 
and  audio  to  achieve  the  most  desirable  interface  possible. 

The  environment  in  which  Threat  Evaluator  was  developed  is  Hypercard^*^, 
whose  scripting  language  is  Hypertalk’''^.  Information  on  this  environment  can 
be  found  in  Apple’s  HyperCard  User’s  Guide  [Ref  3].  This  environment  proved 
to  be  quite  efficient  in  the  production  of  the  prototype  application.  The  Threat 
Evaluator  and  HyperCard  operate  on  Apple  Macintosh™ ‘  computers.  An 
important  point  is  that  Threat  Evaluator  can  be  converted  for  use  on  any 
Microsoft  disk  operating  system  (MSDOS)  platforms  which  would  facilitate  its 
implementation  throughout  the  fleet. 

The  purpose  of  this  thesis  is  to  demonstrate  the  feasibility  of  a  tactical 
evaluation  tool  that  will  aide  in  the  identification  of  platforms  that  may  pose  a 
possible  threat  to  U.S.  forces.  The  tool  will  also  give  the  TAO  relevant  own 
ship’s  information  so  that  tactical  decisions  can  be  made  knowing  all  required 
information. 


‘HyperCard™  and  Hypertalk™  are  trademarks  of  Apple  Computer 
Incorporated. 
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II.  PROBLEM  STATEMENT 


One  of  the  most  important  qualifications  and  subsequent  duties  of  a  Surface 
Warfare  Officer  is  that  of  TAO.  It  is  the  pinnacle  qualification  that  a  junior 
officer  can  achieve  resulting  from  training,  acquired  knowledge  and  trust .  It  is 
also  quite  an  identifiable  achievement  a  CO  can  bestow;  proclaiming  that  a  junior 
officer  is  capable  of  fighting  the  ship  in  battle.  The  CO  that  conducts  the 
qualifying  process  puts  great  trust  in  each  of  the  officers  that  he  or  she  qualifies. 
Stringent  qualification  requirements  and  thorough  knowledge  of  own  ship  and 
other  potentially  hostile  ship’s  characteristics  and  capabilities  are  essential  to 
proficiency  and  success  as  a  TAO. 

Although  the  TAO  position  is  quite  important  and  essential,  after  the 
qualification  process  has  been  completed  there  is  little  continuous  training 
conducted  to  maintain  this  high  degree  of  readiness.  Continued  training  is 
usually  left  to  each  TAO  with  little  or  no  guidance.  Nonnal  means  of  keeping 
proficient  is  rote  memorization.  This  process  may  be  helpful  in  the  short  term, 
but  must  be  continually  refreshed  in  order  to  keep  the  knowledge  base  readily 
available  and  current  in  memory.  It  is  difficult  for  the  TAO  to  keep  current  all 
hostile,  or  potentially  hostile,  ships  memorized  and  easily  accessible  at  a  moments 
notice.  The  will  to  train  is  often  hampered  by  the  sheer  mass  of  data  that  must 
be  memorized.  The  unappealing  volumes  that  contain  the  data  must  also  be 
learned  to  use.  Methods  that  will  give  the  data  more  appeal  and  even  an  exciting 
means  of  learning  required  knowledge  would  pique  interest  while  being 
functional  and  informative. 

Another  problem  encountered  in  the  normal  watch  duties  of  the  TAO  is  the 
time  consuming  evaluation  of  each  emitter  signal  detected.  The  usual  flow  of 
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information  starts  with  the  detection  of  an  emitter  by  the  Electronic  Warfare 
^W)  suite  aboard  After  the  initial  detection,  search  algorithms  on  the  detection 
equipment  attempt  to  make  a  match  with  the  signal  detected.  This  search  usually 
takes  longer  than  desired  and  may  result  in  an  incorrect  evaluation.  The  search 
algorithm  itself  may  not  be  optimal  resulting  in  a  slow  search  and  retrieval 
process.  The  search  is  also  conducted  manually  by  EW  personnel  using  printed 
reference  volumes.  This  is  done  in  order  to  reduce  the  number  of  erroneous 
matches  that  result  from  software  searches  alone.  The  whole  process  is  time 
consuming  and  prone  to  errors. 

Current  tools  available  to  U.S.  Navy  Combat  Information  Center  (CIC) 
watchstanders,  all  of  whom  work  for  the  TAO,  for  threat  evaluation  and 
recognition  training  are  limited.  Naval  Warfare  Publications  (NWP),  are  used  to 
search  for  data  that  is  of  primary  concern.  Of  note,  there  is  no  quick  reference 
available  for  correlation  of  essential  initial  identification  information  while  in  a 
tactical  environment.  By  its  very  nature,  this  limits  the  flow  of  critical 
information  that  the  TAO  must  have  to  support  the  decision  making  process. 
Loss  of  time  conducting  manual  searches  for  information  contained  in  hard  copy 
volumes  adversely  affe'^ts  the  defensive  posture  of  a  single  ship  as  well  as  the 
overall  combat  readiness  on  an  entire  battlegroup. 

The  effective  transfer  of  information  during  watch  turnover  is  crucial  to 
watch  continuity.  Word  of  mouth,  status  boards,  notes  scribbled  on  paper  and 
even  seemingly  organized  notebooks  have  been  the  historical  means  of 
transferring  current  tactical  as  well  as  material  status.  Although  this  may  prove 
effective  in  an  isolated  number  of  cases,  for  the  most  part  essential  information  is 
left  out  or  altered  slightly  by  the  typical  watch  to  watch  turnover.  If  notebooks 
are  used  for  turnover  information,  the  notebooks  or  status  boards  may  not  be 
updated  in  a  timely  matter,  or  may  even  be  totally  neglected.  Additional  clutter 
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is  the  result  of  paper  turnovers  and  it  leaves  the  oncoming  watchstander  sorting 
the  remaining  pile  for  useful  bits  of  information.  Visual  means  of  exchanging 
data  on  electronic  media  is  the  most  efficient  choice  available.  Off  the  shelf 
technology  can  provide  significantly  more  efficient  data  retrieval  and  a  graphical 
interface  that  will  aid  this  entire  process. 

A  review  of  current  procedures  and  firet  hand  experience  have  revealed  a 
number  of  items  that  should  be  improved  for  greater  efficiency.  These  are: 

•  Resources  are  currently  manual  in  nature,  often  leading  to  slow,  inefficient 

information  retrieval.  Unwieldy  pubfcations  and  microfiche  are  the 
primary  mechanisms  for  data  storage  and  the  only  vehicle  for  training 
watchstanders. 

•  After  qualification,  TAO’s  typically  have  no  formal  training  in  threat 

evaluation  as  a  means  of  maintaining/improving  proficiency. 

•  Reference  and  training  tools  are  not  centralized,  often  requiring  users  to  visit 

various  locations  to  collate/coordinate  the  tools  and  information  and  to  have 
access  to  the  proper  equipment. 

•  The  lack  of  user  friendly  aids  to  threat  evaluation  is  often  frustrating  to 

many  TAO’s. 

Automation  of  many  of  the  manual  functions,  such  as  searching  databases  and 
recording  critical  watch  information  to  relieving  watchstanders,  would  greatly 
improve  the  efficiency  of  the  evaluation  process.  There  are,  however,  factors 
that  would  be  of  primary  concern  in  determining  the  implementation  of  such  an 
application.  These  factors  are  reliability  of  the  hardware  system  and  the  ease  of 
use  of  the  application. 

The  reliability  of  the  system  includes  many  items.  Preferably,  it  should  be 
more  reliable  than  systems  currently  in  use.  Methods  of  protecting  data  and 
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applications  from  viruses  as  well  as  disk,  system  and  application  crashes  should 
be  carefully  considered.  A  variety  of  media  exists  for  data  backup.  Floppy 
disks,  tapes,  optical  disks,  hard  disks  and  removable  hard  disks  are  all  readily 
available  and  accessible. 

Data  updates  are  of  primary  concern  to  the  user.  The  importance  of  having 
accurate,  time  sensitive  information  is  critical.  Efficient  and  easy  methods  of 
updating  existing  information  would  be  important  in  saving  time  and  effort  as 
well  as  money.  Determining  the  best  possible  method  of  delivering  updated 
information  is  also  a  crucial  problem. 

The  emphasis  on  ease  of  use  cannot  be  over  stressed.  The  goal  is  to  make  the 
application  intuitive,  therebv  allowing  novice  users  easy  access  to  its  capabilities. 
If  the  application  requires  enormous  manuals  and  cryptic  documentation  be  read 
and  filtered  prior  to  use,  then  ultimately  the  product  will  not  be  used. 
Determining  which  environment  will  best  suit  this  requirement  is  an  important 
undertaking. 
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III.  SOLUTION 


The  recommended  solution  and  the  focus  of  this  thesis  research  is  the 
automation  of  numerous  manual  tasks  that  are  conducted  by  the  TAO  and  other 
watchstanders.  Automation  of  procedures  would  simplify  and  streamline  the 
warfighting  capability  of  any  warship.  The  speed  at  which  many  of  the 
procedures  can  be  accomplished  through  automation  will  significantly  increase 
productivity  of  a  TAO  and  his/her  watch  team.  This  solution  is  composed  of 
both  hardware  and  software.  Both  are  crucial  to  ensure  successful  operation  and 
integration  of  a  total  system  into  the  fleet. 

A.  HARDWARE  SOLUTION 

Hardware  is  vitally  important  in  an  enclosed  shipboard  environment  because 
space  is  scarce.  The  smaller  a  system  is,  the  better  it  will  support  limited  space 
of  fleet  units.  A  micro  computer  is  an  excellent  choice.  The  cost  of  micro 
computers  has  dropped  dramatically  in  recent  years  and  they  have  become  quite 
affordable.  Micro  computers  with  speeds  in  the  16MHZ-25MHZ  can  be 
purchased  for  under  $3000.  Most  micro  computers  contain  a  number  of 
additional  features  such  as  sound,  expansion  slots  and  network  capabilities  which 
ensure  a  system  could  be  expanded  to  meet  future  requirements. 

The  ability  of  the  micro  computer  to  support  sound  is  an  important  factor. 
For  example,  sound  can  be  a  critical  feature  in  the  evaluation  of  EW  parameters. 
Sound  capability  could  assist  the  users  in  identifying  various  platforms  by 
matching  emitter  parameters  contained  on  those  platforms.  Other 
implementations  of  sound,  such  as  acoustic  signatures,  could  be  used  to  further 
enhance  the  solution.  Speakers  and  associated  sound  supporting  equipment 
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should  come  included  in  the  micro  computer  rather  than  having  to  buy  an 
additional  equipment  in  order  to  add  this  feature.  This  will  provide  two  benefits: 
first,  is  the  elimination  of  requirements  to  have  the  expertise  and  tools  available 
to  install  sound  equipment;  second,  the  cost  of  buying  required  sound  equipment 
would  be  avoided.  The  micro  computer  that  includes  sound  capabilities  may  be 
slightly  more  expensive  in  the  initial  purchase,  but  when  the  cost  of  the 
installation  tools,  the  installation  of  the  sound  equipment,  and  the  sound 
equipment  itself  are  added  to  the  price  of  the  micro  computer  that  did  not  have  it 
previously  installed,  the  result  is  an  overall  lower  cost  for  the  one  having  the 
capability  built  into  the  micro  computer. 

The  ability  of  a  micro  computer  to  be  expandable  is  also  crucial  in  the 
selection  of  a  micro  computer.  Many  micro  computers  have  expansion 
capabilities  available  through  expansion  slots.  Expansion  slots  provide  the  means 
of  installing  additional  cards  that  add  useful  features.  These  capabilities  include 
24  bit  color,  file  compression  and  networking.  It  is  important  that  future 
requirements  be  considered  when  selecting  a  micro  computer  for 
implementation. 

The  ability  of  a  micro  computer  to  support  networking  is  fast  becoming  an 
essential  part  of  any  computer  solution.  The  ability  to  share  data  and  resources 
between  multiple  user  computers,  as  well  as  different  types  of  computers,  is  a 
significant  attribute.  A  multi-user  environment  is  necessary  for  complete 
implementation  of  a  solution.  Users  typically  use  only  a  portion  of  data  from  the 
solution  application.  Examples  of  multiple  users  that  would  use  a  solution 
application  may  be  the  CO,  Executive  Officer,  Department  Heads,  TAO’s,  and 
on-watch  personnel  such  as  those  in  the  CIC,  EW  and  ASW  modules.  A 
networking  capability  must  be  available  in  the  micro  computer  selected. 
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An  important  part  of  a  hardware  solution,  in  addition  to  the  micro  computer, 
is  a  monitor.  A  monitor  is  essential  for  displaying  data  that  is  generated  from 
the  micro  computer  and  solution  application.  Over  the  last  few  years,  monitors 
have  become  quite  inexpensive.  High  resolution  color  monitors  can  be  purchased 
for  approximately  $500.  The  resolution  of  the  monitor  is  important  because  the 
graphics  that  will  be  displayed  in  the  application  must  be  clear.  A  thirteen  inch 
monitor  having  a  640  by  480  pixel  display  with  72  dots  per  inch  (dpi)  resolution 
should  be  sufficiently  high  in  resolution  to  show  the  required  graphics. 

B.  SOFTWARE  SOLUTION 

When  considering  a  specific  software  environment  to  be  used  in  the 
generation  of  a  solution  application,  there  are  a  number  of  criteria  that  should  be 
evaluated  in  order  to  choose  the  most  desirable  option.  These  criteria  can  best  be 
described  as  features  that  the  environment  will  support.  These  features  for  a 
development  environment  include  reusable  code,  modularity  and  rapid 
prototyping  capabilities.  Features  of  the  solution  application  include:  a 
multimedia  interface,  rapid  search,  display  of  windows,  graphics,  sound,  tailored 
menu  capabilities  and  machine  independence. 

1.  Development  Environment 

The  software  development  environment  chosen  should  support  two 
main  features.  The  first  is  modular  design  and  the  second  is  reusable  code.  This 
is  by  no  means  an  exhaustive  list  of  requirements,  but  these  two  are  certainly 
essential  to  the  solution  of  this  specific  problem. 

The  development  environment  must  support  a  modular  program  design. 
This  design  will  make  the  expansion  of  the  solution  application  much  easier  to 
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implement.  Whitten,  Bentley,  and  Barlow  [Ref  4]  say  the  following  about 
dividing  a  program  into  modules: 

Given  these  programs,  we  want  to  break  them  into  manageable 
modules  around  which  program  specifications  will  be  written. 
Programmers  can  then  build  and  test  each  module  independently. 

Then  modules  can  be  integrated  according  to  the  structure  chart 
and  tested  as  a  whole  program. 

This  approach  to  program  design  would  enhance  the  solution  application  since 
the  program  data  would  lend  itself  to  a  modular  design.  For  example,  some  of 
the  required  data  would  be  divided  into  countries.  Each  of  the  country  modules 
would  contain  the  information  on  the  equipment  and  platforms  owned  by  that 
country. 

Reusable  code  has  become  a  buzzword  in  the  software  development 
community.  Reusable  code  promotes  efficiency  in  the  development  of  new 
applications  or  new  modules  that  will  be  add-ons  to  existing  applications. 
Reusable  code  still  requires  some  modification,  however  the  savings  that  such 
code  generates  makes  the  cost  of  such  changes  insignificant  when  taken  in 
aggregate.  Powers,  Cheney,  and  Crow  [Ref  5]  state  the  following: 

Systems  designers  have  long  been  interested  in  the  concept  of 
reusable  code.  The  idea  is  to  write  general  purpose  modules  that 
can  be  used  in  many  programs,  thereby  reducing  the  overall 
programming  and  testing  effort  during  development  and 
simplifying  the  on-going  maintenance  effort.  The  large  majority  of 
program  code  involves  routine  processes  such  as  data  entry  and 
verification,  file  maintenance,  and  report  writing.  It  should  be 
possible  to  create  a  standard  set  of  modules  supporting  these 
operations  that  could  constitute  70  to  80  percent  or  more  of  the 
code  for  a  new  system. 
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These  two  factors,  modularity  and  reusable  code,  contribute  to  a  rapid 
prototyping  environment  that  would  support  quick  delivery  of  a  product  to  the 
fleet.  Prototyping  is  an  excellent  way  to  determine  additional  requirements  and 
solutions  before  the  final  product  is  distributed  to  end  users. 

2.  Application  Solution 

This  solution  application  includes  a  multimedia  interface  for  real  time 
databases  that  supports  text,  graphics  and  audio.  This  capability  would  be 
required  to  provide  the  needed  data  that  a  TAO  would  use  in  the  course  of 
his/her  duties.  These  capabilities  are  also  essential  in  displaying  that  data  in  a 
timely,  easy  to  assimilate  manner. 

This  application  must  have  a  rapid  search  capability.  From  a  users’ 
perspective  this  feature  is  quite  important.  In  a  tactical  environment,  a  rapid 
search  could  mean  the  difference  between  the  success  or  failure  of  a  mission. 
Vast  amounts  of  data  must  be  searched  increasing  the  need  for  a  search  to  be  fast 
and  accurate. 

The  manner  in  which  information  is  displayed  is  very  important.  The 
user  should  be  able  to  easily  distinguish  different  parts  or  categories  of 
information  from  one  another.  An  ideal  way  to  do  this  is  to  display  the 
information  in  windows  that  appear  as  specific  queries  are  selected  by  the  user. 
This  provides  a  quick  means  of  assimilating  data.  The  solution  application 
should  support  this  method  of  data  display.  From  a  human  factors  point  of  view, 
this  is  a  better  interface. 

Graphics  are  an  essential  part  of  this  solution  application.  They  are 
used  to  enhance  recognition  of  platforms  for  training  and  tactical  situations  and 
also  to  make  the  interface  user  friendly.  The  power  of  a  user  friendly  interface 
cannot  be  underestimated.  The  easier  it  is  to  understand  and  use  the  application, 


11 


the  greater  value  it  will  provide  end  users  as  a  tool  for  accomplishing  their 
missions.  Graphical  user  interfaces  provide  clear,  concise  object  relationships 
that  a  user  with  only  modest  experience  can  easily  associate.  Pictures  of  familiar 
objects  on  the  screen  guide  a  user  to  operate  the  application.  A  user  sees  an  icon 
in  the  shape  of  a  missile,  he  or  she  should  expect  information  about  missiles  to 
come  from  using  that  icon.  The  interface  is  intuitive  which  adds  to  the 
desirability  of  the  application.  Considerable  thought  and  study  must  be 
incorporated  in  the  design  of  an  interface.  Graphical  capability  is  a  means  to 
achieving  this  desired  result. 

Sound  is  another  method  of  providing  information  to  the  user.  For 
example,  sound  could  be  used  to  distinguish  one  level  of  a  program  from  another 
or  to  provide  an  audible  alarm  that  will  alert  the  user  if  needed.  There  are  many 
other  options  that  could  also  employ  sound  to  assist  the  user. 

In  order  for  an  application  to  be  adapted  to  a  specific  use,  menus  of  the 
program  should  be  tailored  to  support  needed  functions  and  information. 
Tailored  menus  allow  the  user  to  quickly  identify  his  or  her  options  for 
retrieving  desired  data.  Menus  support  the  proper  setup  and  flow  of  information 
to  the  user. 

It  is  crucial  that  the  application  be  machine  independent  and 
transportable  to  other  hardware.  This  would  then  allow  the  application  to  be 
available  on  most  hardware  in  use  in  the  fleet.  True  machine  independence 
provides  an  application  with  an  enonnous  platform  base  upon  which  to  operate. 
Access  by  all  fleet  users  increases  the  ability  to  develop  and  capitalize  on  large 
user  groups. 
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IV.  IMPLEMENTATION 


A.  OVERVIEW 

The  Threat  Evaluator  was  developed  in  a  HyperCard  environment  on  a 
Macintosh  II  computer.  HyperCard  comes  free  as  system  software  with  all 
Macintosh  computers.  The  assumption  in  this  chapter  is  that  readers  are  familiar 
with  HyperCard.  In  Threat  Evaluator,  all  algorithms  and  modules  have  been 
thoroughly  considered  throughout  the  development  process.  Threat  Evaluator 
can  be  implemented  as  an  additional  module  to  the  Argos  System  or  as  a  stand 
alone  application.  For  the  purpose  of  the  prototype,  the  Threat  Evaluator  is 
made  up  of  five  modules  and  is  modelled  after  a  FFG-7  class  ship  There  is  the 
Threat  Evaluator  module,  the  U.S.  Aircraft  data  file,  the  U.S.  Surface  Ship  data 
file,  the  U.S.  Submarine  data  file  and  the  Threat  Evaluator  Help  data  file.  The 
modular  design  was  considered  the  best  option  for  future  expansion  of  this 
application  because  every  country  that  has  militaiy  equipment  would  be  modelled 
in  a  data  file.  For  example,  Germany  would  have  its  own  data  file  containing 
information  on  its’  platforms.  This  modular  approach  also  conforms  to  the 
design  of  the  Argos  system.  The  Threat  Evaluator  is  the  most  tailored  tool  to 
date  that  gives  a  TAG  continuous  personal  training  as  well  as  evaluation  of 
platforms  that  may  pose  a  possible  threat  to  the  safety  of  the  ship. 

HyperCard  has  met  all  the  criteria  for  the  software  environment  solution.  It 
supports  both  modularity  and  reuseable  code.  Reuseable  code  features  of 
HyperCard  support  a  high  percentage  of  the  code  needed  for  development  of  all 
the  modules. 
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B.  STARTUP  SCREEN  AND  MAIN  MENU  CARDS 


The  startup  screen  displays  high  resolution  graphics  and  plays  digitized 
soundt  to  show  the  many  capabilities  of  HyperCard  and  a  Macintosh  as  soon  as 
possible.  A  picture  of  a  U.S  Aegis  cruiser  was  placed  over  a  background  that  has 
a  marble  like  appearance.  This  was  done  to  give  the  user  the  feeling  of  viewing 
a  warship  in  a  background  of  space  giving  a  futuristic  appearance.  The  sound 
was  used  to  welcome  the  user  to  the  Threat  Evaluator  as  well  as  demonstrate 
digitized  sound.  The  command  to  play  the  sound  is  contained  in  the  card  script. 
Digitized  sounds  for  the  stacks  were  installed  using  the  MacRecorder®  by 
Farallcn™2,  These  sounds  were  then  placed  into  the  main  Threat  Evaluator  stack 
as  resources.  These  resources  could  then  be  called  and  played  as  required. 

The  startup  screen  dissolves  into  the  main  menu  screen.  This  visual  effect 
was  included  to  demonstrate  one  of  the  many  screen  change  features  of 
HyperCard.  The  dividing  line  in  the  center  of  the  main  menu  screen  is  used  to 
distinguish  training  areas  from  actual  tactical  applications.  The  training  portion 
of  the  screen,  above  the  separation  line,  has  three  card  layer  buttons.  The  three 
areas  modeled  were  aircraft,  surface  ships,  and  submarines.  Each  of  these  card 
buttons  has  an  associated  icon  that  correlates  the  name  displayed  to  the  button. 
For  example,  the  aircraft  button  has  an  icon  in  the  shape  of  a  jet.  This  was  done 
to  give  an  additional  visual  confirmation  to  the  user  of  what  is  being  selected 
when  he  or  she  clicks  on  that  button.  Each  of  the  buttons  calls  an  external 
command  (XCMD)  that  generates  a  popup  menu.  The  countries  contained  in  the 
popup  menus  for  each  of  the  aircraft,  surface  ships  and  submarines  buttons  are 


2  MacRecorder®  is  copyrighted  by  Farallon  Computing  Incorporated. 
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categorized  in  accordance  with  the  International  Institute  for  Strategic  Studies’ 
(nSS)  yearly  publication  [Ref.  6].  This  publication  provides  a  well  organized 
categorization  of  various  countries.  The  country  and  department  modeled  on  the 
aircraft  and  surface  ships  card  buttons  is  the  United  States  and  the  U.S.  Navy 
(USN).  The  United  States  is  modeled  on  the  submarines  card  button.  The  scripts 
for  the  aircraft,  surface  ships,  and  submarine  menus  are  contained  in  Appendix 
A.  The  categories  provided  by  the  IISS  were  determined  to  be  a  reasonable 
maimer  in  which  to  categorize  the  data  within  the  Threat  Evaluator. 

Selection  of  items  on  the  popup  menus  contained  in  the  aircraft,  surface  ships 
and  submarine  card  buttons  take  the  user  to  a  second  level  menu  screen.  The 
specific  country  or  department  chosen  from  that  first  menu  is  broken  down  into 
the  various  agencies  on  the  second  menu  screen.  These  agencies  have  control  of 
the  equipment  (aircraft,  surface  ships,  submarines)  selected  from  the  first  menu 
screen.  For  example,  after  selection  of  “USN”  under  the  aircraft  card  button  on 
the  first  menu  screen,  the  screen  changes  to  display  the  types  of  squadrons 
associated  naval  aircraft.  The  user  then  has  access  to  the  individual  aircraft  type 
within  each  squadron  designation.  These  squadron  designations  are  in 
accordance  with  Ball  [Ref  7).  Representative  scripts  for  the  second  menu  screen 
card  buttons  are  contained  in  Appendix  A.  The  second  menu  screen  has  a 
horizontal  dividing  line  to  differentiate  fixed  wing  aircraft  from  helicopters. 
This  provides  another  visual  confirmation  to  the  user.  Squadrons  and  ship 
classes  are  not  all  inclusive  but  were  chosen  to  represent  different  communities. 

C.  INFORMATION  CARDS 

After  a  specific  aircraft,  surface  ship  or  submarine  is  chosen  from  the  second 
main  menu  screen  the  user  is  then  shown  the  card  with  that  specific  platform. 
On  the  card  there  are  features  that  will  be  of  assistance  to  the  user  in 
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categorizing  the  possible  threat  to  his  own  ship.  Capabilities  of  the  platforms  are 
divided  into  the  four  warfare  areas  modeled.  The  warfare  areas  chosen  were 
anti-air  warfare  (AAW),  anti-surface  warfare  (ASUW),  anti-submarine  warfare 
(ASW),  and  electronic  warfare  (EW).  Not  all  warfare  areas  were  modeled  due 
to  time  constraints.  Labels  for  the  card  button  associated  with  the  warfare  areas 
were  placed  into  the  background  because  these  labels  would  be  used  on  all 
platforms  within  the  stack.  The  actual  buttons  were  placed  in  the  card  layer 
because  the  popup  menu  would  have  to  be  tailored  for  each  platform.  These 
card  buttons  can  be  copied  and  used  in  new  cards  and  easily  modified  for  other 
platforms  since  the  script  is  copied  along  with  the  card  button.  Repetition  of 
equipment  that  appears  under  these  warfare  menus  is  purposely  done  to  show  the 
possibilities  of  using  a  certain  system  in  more  than  one  mode  or  warfare  area. 
For  example,  a  surface  to  air  missile  may  also  be  used  in  a  surface  to  surface 
mode.  This  repetition  would  assist  the  TAO  in  remembering  the  capabilities  of 
various  weapons.  Scripts  for  the  warfare  area  buttons  are  contained  in  Appendix 
A.  Equipment  and  systems  listed  in  the  menus  for  the  F/A-18  Hornet  [Ref  8],  the 
Oliver  Hazard  Perry  class  frigate  [Ref  9],  and  the  Los  Angeles  class  submarine 
[Ref  10]  were  taken  from  Jane’s  Fighting  Ships  and  Jane’s  All  The  World’s 
Aircraft. 

After  a  weapon  or  electronic  system  is  selected  from  the  menu  of  a  warfare 
area,  a  window  appears  containing  specific  data  and  characteristics  that  a  TAO 
may  require  for  proper  tactical  evaluation.  The  windows  are  actually  card  fields 
being  displayed  upon  the  selection  of  a  menu  item.  The  use  of  card  fields  was 
determined  to  be  ideal  in  separating  system  data  in  a  logical  systematic  manner 
and  providing  a  visual  consolidation  of  information  for  the  user.  Card  fields 
containing  data  have  been  locked  to  prevent  inadvertent  alteration  of  the  data. 
This  gives  an  added  measure  of  security  as  well  as  ensuring  that  data  remains 
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intact.  There  are  many  card  fields  containing  information  on  each  card.  Each  is 
given  a  specific  name  and  that  name  is  placed  in  the  script  of  the  applicable 
warfare  area  button.  Once  the  field  is  displayed,  it  can  be  hidden  again  by 
clicking  the  cursor  within  the  field.  This  format  of  displaying  data  will  be  useful 
in  training  prospective  TAO’s.  The  method  of  data  display  is  also  useful  for 
training  prospective  TAO’s  since  on-line  quizzing  can  be  accomplished  within 
each  warfare  area. 

D.  SEARCH  AND  IDENTIFY  FUNCTION 

One  of  the  most  crucial  and  useful  functions  available  to  the  TAO  in  the 
Threat  Evaluator  application  is  the  Search  and  Identify  option.  This  option  is 
located  on  the  main  menu  screen  for  easy  access  by  the  user  and  is  vital  for  quick 
identification  of  an  incoming  threat  associated  with  a  particular  emitter  or 
weapon  system.  The  search  and  identify  screen  contains  three  card  fields,  one  of 
which  is  hidden.  The  name  of  the  hidden  card  field  is  “stacks  to  search”.  Scripts 
[Ref  11]  for  the  visible  fields  are  found  in  Appendix  A.  The  first  field  receives 
the  search  string  that  will  be  compared  to  all  the  data  card  fields  of  the 
information  stacks.  The  search  algorithm  will  search  each  stack  that  is  listed  in 
the  hidden  field.  Additional  stacks  that  are  created  would  merely  need  to  be 
added  to  this  field.  Upon  a  match  of  the  search  string  and  the  name  of  a  data 
field,  the  name  of  the  card  and  the  name  of  the  stack  in  which  a  match  was  found 
is  returned  and  displayed  in  the  second  visible  field. 

The  second  field  displays  the  name  of  the  platform  and  the  name  of  the  stack 
on  which  the  platform  is  located.  These  are  separated  by  a  comma  and  the 
number  of  matches  displayed  is  unlimited.  If  a  TAO  desires  further  information 
on  a  particular  platform,  he  or  she  merely  uses  the  mouse  to  click  on  the  desired 
platform’s  name  and  the  information  card  for  that  platform  is  displayed  instantly 
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by  pushing  the  search  card.  This  is  done  so  that  the  user  can  return  to  the  search 
card  and  evaluate  further  matches.  The  card  field  displaying  the  results  of  the 
search  is  locked  to  permit  the  routine  to  woric.  This  routine  was  considered  an 
essential  function  of  the  search  card.  The  TAO  had  to  have  the  capability  to 
quickly  evaluate  the  results  of  the  search  without  having  to  navigate  back  through 
menus.  This  routine  allows  the  TAO  to  evaluate  in  detail  the  capabilities  of  each 
of  the  platforms  found  by  the  search. 

E.  TAO  STATUS  BOARD 

The  TAO  status  board  was  created  to  give  a  TAO  a  place  to  record 
information  that  was  critical  for  the  proper  conduct  of  the  watch.  He  or  she  also 
needed  a  place  to  record  any  information  that  would  be  pertinent  for  following 
watch  sections.  The  TAO  status  board  is  an  ideal  tool  for  easy  access  to  all 
required  ships’  infonnation.  The  TAO  status  board  is  comprised  of  two  cards 
that  display  critical  ships  information.  The  combination  of  these  two  cards 
assures  that  the  TAO  has  available  all  data  essential  to  fighting  the  ship.  Two 
cards  were  determined  appropriate  to  hold  all  the  information  that  would  be  of 
importance  while  not  requiring  an  excessive  amount  of  searching  by  the  TAO 
through  many  cards.  The  first  card  was  chosen  to  hold  general  data  that  would 
be  easy  to  assimilate  at  a  glance.  The  second  card  was  constructed  to  hold  more 
detailed  data  regarding  the  casualties  of  various  engineering  and  combat  systems. 

The  first  card  of  the  TAO  status  board  displays  tactical  weapons  systems’ 
information.  Weapons  status  and  condition  of  readiness  are  displayed  at  the  top 
of  the  screen.  The  position  of  this  was  important  because  a  TAO  must  first  be 
aware  of  the  weapons  status  ordered.  The  screen  is  essentially  divided  into  three 
main  segments  in  order  to  logically  collate  data.  The  segment  on  the  left  of  the 
screen  contains  ASW  related  information  including  associated  weapon’s  systems. 
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Information  such  as  the  mode  of  the  sonar,  water  conditions  for  the  day  and 
torpedo  loading  data  are  essential  for  ASW  operations.  Radio  buttons  (which  are 
small  round  buttons)  and  text  fields  were  used  to  accept  and  display  information. 
The  torpedo  tube  graphic  serves  to  give  the  user  a  visual  reference  of  which 
tubes  are  currently  loaded.  The  segment  on  the  right  of  the  screen  contains 
information  on  the  installed  gun  systems.  This  information  would  be  required  in 
any  AAW  or  ASUW  engagement.  Information  is  also  displayed  through  the  use 
of  text  fields  and  buttons.  The  segment  on  the  lower  center  of  the  screen  shows 
the  remaining  missiles  and  their  respective  locations  in  the  magazine.  This 
display  gives  the  TAO  a  visual  perspective  as  to  the  remaining  missiles  and  their 
locations  after  a  firing.  Each  of  the  cells  contain  four  buttons,  each  symbolizing 
the  three  types  of  rounds  (SM-1,  blue  bird,  harpoon)  plus  an  empty  cell  symbol 
that  would  be  generated  once  a  missile  from  that  cell  was  fired.  The  symbols 
chosen  were  representative  of  the  actual  rounds  and  an  empty  cell  was  given  an 
“x”  symbol. 

The  second  screen  of  the  TAO  status  board  is  divided  into  two  main  sections. 
The  left  side  of  the  screen  is  the  combat  systems  status  and  the  right  side  of  the 
screen  is  the  engineering  status.  This  information  is  very  important  to  the  TAO 
because  the  material  condition  of  either  of  these  two  areas  directly  affects  the 
combat  readiness  and  the  survivability  of  a  ship  in  combat.  If  there  is  any 
degradation  in  the  equipment,  then  the  TAO  must  be  aware  of  what  is  not 
working  and  what  effect  its’  failure  has  on  the  combat  readiness  of  the  ship. 
Card  text  fields  were  considered  necessary  to  hold  information  on  what 
equipment  has  a  casualty,  what  effect  the  casualty  has  overall  and  what,  if  any, 
scheduled  maintenance. 
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F.  TACTICAL  ALGORITHMS 

This  module  has  not  been  developed.  A  stub  was  placed  here  indicating 
future  possibilities.  Ideally,  it  should  be  capable  of  using  tactical  algorithms  that 
would  calculate  the  probability  of  kill  (Pk)  against  a  particular  target  with  a 
selected  ship’s  weapon.  This  would  then  give  the  TAO  the  optimum  weapon 
release  point  against  that  target  and  the  number  of  weapons  to  use  in  any  given 
engagement.  The  TAO  would  then  have  a  solid  recommendation  on  which  to 
base  his  final  decision. 

G.  INTER-STACK  BACKGROUND  BUTTONS 

There  are  a  number  of  references  which  a  TAO  must  read  and  be  familiar 
with.  These  written  orders  should  be  easily  accessible  to  the  TAO.  Throughout 
each  of  the  modules  of  Threat  Evaluator,  the  TAO  has  access  to  a  number  of 
background  buttons.  The  background  buttons  of  note  are  Battle  Orders,  Ruies  of 
Engagement  (ROE),  Night  Orders,  Pass  Down  Log  (PDL),  INCSEA  signals  and 
Allied  Tactical  Publication  (ATP)  signals. 

Battle  orders,  ROE,  night  orders  and  PDL  cards  were  constructed  in  the 
same  format.  A  scrolling  field  was  chosen  to  hold  the  data.  This  field  can 
expand  as  the  amount  of  data  grows.  The  field  will  hold  a  total  of  30,000 
characters  [Ref  12].  A  button  prints  the  time  and  date  into  the  field  when 
required  by  the  user.  The  time/date  stamp  was  considered  necessary  so  that  the 
user  could  identify  any  new  entries  since  the  last  time  he/she  read  the  file. 

The  INCSEA  background  button  displays  a  card  that  defines  the  future  use  of 
this  module.  The  module  would  contain  all  the  signals  from  the  INCSEA 
agreement.  These  signals  would  be  displayed  either  in  a  list  or  a  specific  signal 
could  be  encoded/decoded  as  required.  The  signal  would  be  input  by  the  TAO, 
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resulting  in  the  encoded/decoded  signal  displayed  on  the  screen.  Construction  of 
this  module  is  a  follow-on  to  this  thesis. 

The  ATP- 1(C)  background  button  displays  a  card  that  defines  the  planned 
future  use  of  this  module.  This  module  will  contain  all  the  signals  from  the 
ATP- 1(C)  volume  I  and  II.  These  signals  would  be  displayed  either  in  a  list  or  a 
specific  signal  could  be  encoded/decoded  as  required.  The  signal  would  be  input 
by  the  TAO,  resulting  in  the  encoded/decoded  signal  displayed  on  the  screen. 
This  module  is  also  a  follow-on  effort  to  this  thesis. 
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V.  LESSONS  LEARNED 


There  are  several  lessons  learned  from  the  development  of  the  Threat 
Evaluator  application  tool.  Programming  and  interface  standardization  is 
especially  crucial  with  future  modules  that  supplement  the  Threat  Evaluator 
application  since  it  is  an  iterative  and  continuous  development  process.  This 
standardization  would  assist  the  developers  in  the  construction  of  new  modules  or 
data  files.  Important  lessons  learned  include  the  use  of  sound  and  graphics  to 
achieve  unique  methods  of  data  representation.  These  lessons  will  provide 
valuable  information  for  future  module  development. 

The  flrst  lesson  learned  was  in  the  use  of  graphics.  The  careful  utilization  of 
graphics  was  determined  to  be  a  benefit  and  not  a  distraction  to  the  user.  This 
determination  came  from  demonstrating  the  application  to  interested  individuals. 
Graphical  representation  of  familiar  objects  creates  a  more  acceptable 
environment  to  new  users  of  the  application.  Objects  that  appear  in  the  users’ 
normal  work  routine  and  duties  are  taken  and  represented  graphically  in  the 
application.  Implementing  this  graphic  representation  into  the  application  results 
in  the  user  bringing  previous  knowledge  to  the  application.  This  gives  the 
application  an  intuitive  interface.  This  intuitiveness  is  highly  sought  after  in  an 
application  such  as  Threat  Evaluator. 

The  second  lesson  involved  unique  benefits  of  using  sound  as  another  means 
of  transmitting  information  to  the  user.  Sound  provided  the  user  with  a  variety 
of  data.  Digitized  sound  was  used  to  repeat  what  main  menu  function  he  or  she 
was  choosing.  This  supplied  the  user  with  an  audio  confirmation  of  his  or  her 
actions.  Computer  generated  sound  was  used  after  the  first  main  menu  screen. 
The  differentiation  of  digitized  sound  and  computer  generated  sound  gives  the 
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user  the  positive  reinforcement  that  he  or  she  is  in  a  different  part  of  the 
application.  The  demonstration  of  both  types  of  sound  lends  credibility  of  the 
sound  capabilities  and  their  further  expansion  into  other  areas  of  this  application. 

The  third  lesson  learned  was  the  proper  method  of  program  and  data  design 
in  constructing  the  Threat  Evaluator.  Initially,  Threat  Evaluator  began  as  a 
single  stack.  However,  this  became  cumbersome  and  changes  to  the  stack  were 
often  difficult  to  incorporate.  A  modular  concept  of  data  was  determined  as  the 
most  convenient  and  cost  effective  method.  For  future  additions  to  the  Threat 
Evaluator,  modularization  would  facilitate  the  replacement  of  old  data  files  with 
new  ones.  This  modular  concept  allows  a  specific  program  area  or  data  file  to 
be  worked  and  updated  as  necessary,  then  easily  reintroduced  into  the  main 
implication.  This  method  will  reduce  the  code  necessary  for  implementation  in 
fleet  as  opposed  to  a  syston  that  was  not  of  a  modular  composition. 

The  fourth  lesson  learned  was  to  include  proper  documentation  for  the 
application’s  operation.  Appendix  B  contains  a  user’s  manual  that  describes  the 
operation  of  Threat  Evaluator.  This  documentation  assists  the  user  in  the  proper 
operation  of  the  functions  and  features  of  Threat  Evaluator. 
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VI.  CONCLUSIONS 


The  development  of  the  Threat  Evaluator  tool  has  shown  the  feasibility  of  an 
automated  reference  and  evaluation  tool.  The  modular  design  of  the  application 
as  well  as  the  quick  prototyping  aspects  of  the  Hypertalk  language  show  that  the 
HyperCard  environment  can  be  both  economical  and  technically  sound  for  future 
development  of  projects  of  this  sort.  Many  provisions  greatly  needed  by  TAO’s 
have  been  incorporated  into  the  Threat  Evaluator.  These  features  can  be  fine 
tuned  and  tailored  as  further  iterations  of  the  application  are  developed. 

The  storage  media  most  likely  to  be  of  greatest  benefit  for  the  Threat 
Evaluator  is  compact  disk  read  only  memory  optical  storage  (CD  ROM).  This 
would  be  best  for  a  number  of  reasons.  First,  the  CD  ROM  disks  will  hold  about 
550  megabytes  of  data.  This  large  volume  is  necessary  to  hold  all  of  the  data  that 
is  required  for  a  fully  implemented  Threat  Evaluator  application  and  data  files. 
Once  Threat  Evaluator  has  been  completely  implemented,  every  country  that  has 
military  equipment  would  be  represented  by  a  module  that  contained  information 
on  that  equipment.  Today  the  only  true  alternative  for  this  amount  of  data  is  CD 
ROM.  Second,  distribution  of  CD  ROMs  would  be  easy.  Cognizant  agencies 
would  merely  send  new  CD  ROMs  to  fleet  units  as  updates  to  the  data  files  are 
required.  Users  would  then  be  able  to  return  the  old  CD  ROM  for  proper 
destruction  or  sanitization  of  data.  Third,  distribution  disks  would  be  read  only 
memory.  Fleet  personnel  would  not  be  able  to  alter  the  information  contained 
on  the  CD  ROM.  This  ensures  that  all  units  will  have  the  same  data  files. 
Finally,  optical  disks  are  quite  sturdy  and  are  not  easily  damaged  by  normal  day 
to  day  use.  This  will  provide  protection  of  the  data  as  it  is  in  transit  to  the  user 
facility. 
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Future  areas  of  study  directly  relating  to  the  Threat  Evaluator  application 
include: 

•  Development  of  a  module  that  incorporates  probability  of  kill  algorithms  to 

generate  a  recommendation  to  the  TAO. 

•  Development  of  a  module  that  incorporates  the  signals  and  data  in  volumes 

one  and  two  of  ATP  1(C). 

•  Development  of  a  module  that  incorporates  the  INCSEA  signals. 

•  Determination  of  which  storage  media  is  truly  best  for  this  application  to 

include  CD  ROM,  tape  drives  and  removable  hard  disks. 

The  development  of  the  Threat  Evaluator  supports  the  Argos  environment 
and  the  concept  of  a  paperless  ship.  It  provides  the  TAO  with  an  exceptional  tool 
for  analysis  of  tactical  operations.  It  also  provides  the  user  with  a  method  of 
clear  and  concise  information  transfer  between  watch  sections. 
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APPENDIX  A 


SCRIPTS  FOR  THREAT  EVALUATOR 

A.  CODE  FOR  THE  MAIN  MENU  SCREEN  POPUP  MENUS. 

1 .  Aircraft  button 
on  mouseDown 
play  aircraft 

put  "United  States,USN,USAF,USA.USMC,USCG,NOAA"  into  aircraft 
put  return  &  "Soviet  Union"  after  aircraft 

put  return  &  ”NATO,Belgium,Canada,Denmark,France,Germany,Greece,"-i 
&"Iceland,Italy,Luxembourg,Netherlands,Norway,Portugal,Spain,Turkey,"-i 
&”United  Kingdom"  after  aircraft 

put  return  &  "Warsaw  Pact,Bulgaria,Czechoslovakia,Hungary .Poland, ”-i 
&"Romania"  after  aircraft 

put  return  &  "Mideast  &  North  Africa,Algeria,Bahrain,Djibouti,Egypt,"-. 
&"Iran,lraq,IsraeMordan,Kuwait,Lcbanon,Libya,Mauritania,Morroco,"-i 
&"Oman,Qatar,Saudi  Arabia,Somali  Republic,Sudan,Syria.Tunisia,"-. 
&"United  Arab  Emirates.North  Yemen.South  Yemen"  after  aircraft 

put  return  &  "Sub-Saharan  Africa, Angola, Benin,Botswana,Burkina  Faso,”-. 
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&”Bunmdi, Cameroon, Cape  Verde,CentraI  African  Republic,Chad,Congo,”-. 
&’’Ivory  Coast,Equatorial  Guinea,Ethiopia,Gabon,Ghana,Guinea,”-i 
&”Guinea-Bissau,Kenya,Liberia,Madagascar,Mali,Mozambique,Nigeria,”-i 
&”Senegal, Seychelles, Sierra  Leone,South  Africa, Tanzania,Togo,Uganda,”-i 
&’’Zaire,Zambia,Zimbabwe”  after  aircraft 

put  return  &  "Asia  &  Australasia,Afghanistan,Australia,Bangladesh,”-i 
&*’Brunei,Bunna,Cambodia,China,India,Indonesia,Japan,North  Korea,”-i 
&”South  Korea,Laos,Malaysia,Mongolia,Nepal,Pakistan, Papua  New  Guinea,"-i 
&’’Phillipines,Singapore,Sri  Lanka,Taiwan,Thailand,Vietnam,New  Zealand”-i 
after  aircraft 

put  return  &.  "Carribean  &  Latin  America,Argentina,The  Bahamas,Belize,”--i 
&’’Bolivia,Brazil,Chile,CoIombia,Costa  Rica,Cuba,Dommican  Republic,”-. 
&”Ecuador,El  Salvador,Guatemala,Guyana,Haiti,Honduras,Jamaica,Mcxico,”-. 
&”Nicaragua,Panama,Paraguay,Peru,Suriname,Uraguay,Venezuela”-. 
after  aircraft 

get  HPopupMenu(aircraft,0,The  mouse  V,The  mouseH) 
if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  “1)  and  (column  -2)  then 
go  to  card  ”usn” 
end  if 
end  if 

end  mouseDown 
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2.  Surface  Ships  Button 
on  mouseDown 
play  ’’surface  ships” 

put  ”United  States,USN,USA,USCG”  into  ships 
put  return  &  ’’Soviet  Union”  after  ships 

put  return  &  ”NATO,Belgium,Canada,Denmark,France,Gennany,Greece,”-i 
&”Iceland,Italy,Netherlands,Norway,Portugal,Spain,Turkey,”-i 
&”United  Kingdom”  after  ships 

put  return  &  ’’Warsaw  Pact,Bulgaria,Czechoslovakia,Hungary,Poland,”-i 
&”Romania”  after  ships 

put  return  &  ”Mideast  &  North  Africa^lgeria,Djibouti,Egypt,Iran,”-i 
&”lraq,Israel,Jordan,Kuwait,Lebanon,Libya,Mauritania,Morroco,Oman,”-. 
&”Qatar,Saudi  Arabia,Somali  Republic,Sudan,Syria,Tunisia,”-. 

&”United  Arab  Emirates, North  Yemen,South  Yemen”after  ships 

put  return  &  ”Sub-Saharan  Africa,Angola,Benin,Cameroon,Cape  Verde,”-i 
&”Ivory  Coast,Ethiopia,Gabon,Ghana,Kenya,Liberia,Madagascar,Nigeria,”-i 
&”Senegal,Sierra  LeQne,South  Africa,Tanzania”  after  ships 

put  return  &  ”Asia  &  Australasia,Australia,Bangladesh,Brunei,Burma,”-i 
&”Cambodia,China,Fiji,India,Indonesia,Japan,North  Korea, South  Korea,”-i 
&”Malaysia,Pakistan,Papua  New  Guinea,Phillipines,Singapore,Sri  Lanka,”-i 
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A^Taiwan, Thailand, Vietnam»New  Zealand”  after  ships 


put  return  &  ”Carribean  &  Latin  America,Argentina,Bolivia,Brazil,”-i 
&”Chile,Colombia,Cuba,Ecuador,Mexico,Nicaragua,Paraguay,Peru,Uraguay,”-i 
&”Venezuela”  after  ships 

get  HPopupMenu(ships,0,The  mouseV,The  mouseH) 
if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  -  1)  and  (column  =2)  then 
go  to  card  ”usnr’ 
end  if 
end  if 

end  mouseDown 

3.  Submarines  Button 
on  mouseDown 
play  "submarines” 

put  ’’United  States”  into  submarines 

put  return  &  "Soviet  Union”  after  submarines 

put  return  &  ”NATO,Belgium,Canada,Denmark,France,Germany,Greece,”-i 
&”Iceland,Italy,Netherlands,Norway,Portugal,Spain,Turkey,”-. 

&”United  Kingdom”  after  .abmarines 
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put  return  &  "Warsaw  Pact,Bulgaria,Poland,Romania”  after  submarines 

put  return  &  "Mideast  &  North  Africa^lgeria,Egypt,Israel,Libya,”-i 
&"Syria”  after  submarines 

put  return  &  "Sub-Saharan  Africa,South  Africa"  after  submarines 

put  return  &  "Asia  &  Australasia,Australia,China,India,Indonesia,"-i 
&"Japan,North  Korea, South  Korea,Pakistan,Taiwan"  after  submarines 

put  return  &  "Carribean  &  Latin  America,Argentina,Brazil,Chile,"-i 
&"Colombia,Cuba,Ecuador,Peru,Venezuela"  after  submarines 

get  HPopupMenu(submarines,0,The  mouse  V,The  mouseH) 
if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  “  1)  and  (column  =1)  then 
go  to  card  "subs" 
end  if 
end  if 

end  mouseDown 

B.  CODE  FOR  THE  DEPARTMENT/SQUADRON/SHIP  TYPE 
MENUS 
1 .  Aircraft 
on  mouseDown 
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put  ’’FA-18”  into  va 


get  HPopupMenu(va,0,The  mouseV,The  mouseH) 

if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  *  1)  and  (column  =1)  then 
push  card 

go  to  stack  ”u.s.  aircraft” 
end  if 
end  if 

end  mouseDown 

2.  Surface  Ships 
on  mouseDown 

put  ”CG,Belknap,Leahy,Ticonderoga”  into  crudes 

put  return  &  ”CGN,Bainbridge,Califomia,Long  Beach,Truxton 
&”Virginia”  after  crudes 

put  return  &  ”DD,Spruance”  after  crudes 

put  return  &  ”DDG,Adams,Arleigh  Burke,Coontz,Kidd”  after  crudes 
put  return  &  ”FF,Bronstein,Glover,Knox”  after  crudes 
put  return  &  ”FFG, Oliver  Hazard  Perry”  after  crudes 
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get  HPopupMenu(crudes,0,The  mouse  V,The  mouseH) 


if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  “  6)  and  (column  -=2)  then 
push  card 

go  to  stack  ”u.s.  surface  ships” 
end  if 
end  if 

end  mouseDown 
3.  Submarines 
on  mouseDown 
put  ”Ethan  Allen”  into  ssn 

put  return  &  ”Glenard  P.  Lipscomb”  after  ssn 

put  return  &  ”Los  Angeles”  after  ssn 

put  return  &  ”Narwhar  after  ssn 

put  return  &  "Permit”  after  ssn 

put  return  &  "Seawoir  after  ssn 

put  return  &  ’’Skipjack”  after  ssn 


32 


put  return  &  ’’Sturgeon”  after  ssn 


get  HPopupMenu(ssn,0,The  mouse  V,The  mouseH) 

if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  =  3)  and  (column  *1)  then 
push  card 

go  to  stack  ”u.s.  submarines” 
end  if 
end  if 

end  mouseDown 

C.  CODE  FOR  THE  PLATFORM  CARDS 
1.  F/A-18  (Hornet) 
on  mouseDown 

put  ”Guns,20mm  Machine  Gun”  into  aaw 

put  return  &  ”Missiles,Sidewinder,Sparrow”  after  aaw 

get  HPopupMenu(aaw,0,The  mouse  V,The  mouseH) 

if  it  <>  0  then 
put  item  1  of  it  into  ro  w 
put  item  2  of  it  into  column 
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if  (row  *1)  and  (column  ■=  2)  then 
show  card  field  "lOmm” 
else  if  (row  -  2)  and  (column  =  2)  then 
show  card  field  ’’sidewinder^ 
else  show  card  field  ’’sparrow” 
end  if 

end  mouseDown 

2.  Oliver  Hazard  Perry  (FFG-7) 
on  mouseDown 

put  ”Missiles,  Standard  Missile”  into  aaw 

put  return  &  ”Guns,76mm,20mm  CIWS”  after  aaw 

get  HPopupMenu(aaw,0,The  mouse  V,The  mouseH) 

if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  =1)  and  (column  =  2)  then 
show  card  field  ”standard  missile” 
else  if  (row  =  2)  and  (column  =  2)  then 
show  card  field  ”76mm” 
else  show  card  field  ”20mm  CIWS” 
end  if 

end  mouseDown 

3.  Los  Angeles  (SSN  688) 
on  mouseDown 


34 


put  ’’MissilesJHaipoon.Tomahawk”  into  asuw 

put  return  &  "Torpcdos,Mk-48”  after  asuw 

get  HPopupMenu(asuw,0,The  mouseV^The  mouseH) 

if  it  <>  0  then 
put  item  1  of  it  into  row 
put  item  2  of  it  into  column 
if  (row  =1)  and  (column  =  2)  then 
show  card  field  ’Tiarpoon” 
else  if  (row  =1)  and  (column  =  3)  then 
show  card  field  "tomahawk” 
else  show  card  field  ”mk-48” 
end  if 

end  mouseDown 

D.  SEARCH  ALGORITHM  CODE 
1.  Search  script 
on  retuminField 

put  empty  into  card  field  "Found  Card  List” 

set  the  lockMessages  to  true 

set  the  lockRecent  to  true 

set  the  lockScreen  to  true 

put  card  field  "search  criteria"  into  wordToFind 

put  card  field  "stacks  to  search”  into  stacksList 

push  this  card 
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repeat  with  x  -  1  to  the  number  of  lines  in  stacksList 
go  stack  (line  x  of  stacksList) 
unmark  all  cards 

mark  cards  by  finding  wordToFind 
repeat  with  y  »  1  to  the  number  of  marked  cards 
put  (the  short  name  of  marked  card  y)  & 
the  short  name  of  this  stack  &  return  after  foundCardList 
end  repeat 
end  repeat 

delete  last  char  of  foundCardList 
pop  card 

put  foundCardList  into  card  field  ’’Found  Card  List” 
set  the  lockMessages  to  false 
set  the  lockRecent  to  false 
set  the  lockScreen  to  false 
end  retuminField 

2.  Clickline 
on  mouseDown 

get  the  value  of  the  clickLine 
push  card 

go  card  (item  1  of  it)  of  stack  (item  2  of  it) 
end  mouseDown 

3.  Stacks  to  Search 

Card  field  "Stacks  to  Search”  contains  the  following  names: 
u.s.  aircraft 


36 


u.s.  surface  ships 
u.s.  submarines 


APPENDIX  B 


THREAT  EVALUATOR  USER’S  MANUAL 


A.  INTRODUCTION 

The  Threat  Evaluator  is  an  application  that  automates  many  of  the  functions 
that  are  required  during  the  normal  watchstanding  routine  of  a  Tactical  Action 
Officer  CTAO).  Threat  Evaluator  can  be  implemented  as  an  additional  module  to 
the  Argos  System  or  as  a  stand  alone  application.  It  is  the  most  tailored  tool  to 
date  that  a  TAO  has  available  for  continuous  personal  training  as  well  as 
evaluation  of  platforms  that  may  pose  a  possible  threat  to  the  safety  of  the  ship. 

To  start  the  Threat  Evaluator  application,  double  click  on  the  icon  shown  in 
Figure  1. 


Threat  Evaluator 

Figure  1  Threat  Evaluator  Icon 


B.  MAIN  MENU  SYSTEM 

After  startup,  the  user  is  taken  to  the  main  menu  screen  of  the  Threat 
Evaluator  as  shown  in  Figure  2.  From  this  screen  the  user  has  many  options 
available  The  horizontal  dividing  line  in  the  center  of  the  screen  distinguishes 
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Figure  2  Main  Menu  Screen 


the  training  portion  of  the  Threat  Evaluator  application  from  the  tactical 
portions.  The  upper  half  of  the  main  menu  screen  contains  the  aircraft,  surface 
ships  and  submarines  menus  which  make  up  the  training  portion  of  the 
application  or  proceed  to  specific  tactical  operations  such  as  Search  and  Identify, 
TAO  Status  Board  or  Tactical  Algorithms.  Menus  on  the  upper  portion  of  the 
screen  are  accessed  by  clicking  on  the  area  desired,  such  as  Aircraft,  and  holding 
the  mouse  button  down  (see  Figure  3).  This  will  then  show  a  popup  menu  where 
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Sluface  Ships 
Submarines 


Sowbt  Union 
NUTO 

Uloroauf  Pact 
Hidaaat  U  North  (Mca 
Sub-Saharan  Utnca 
Mela  •  Ructralaaia 
Carrlbaan  a  Latin  Rmerlco 


Figure  3  Popup  Menus 


selection  of  a  particular  country  within  a  geographic  region  can  be  made.  In  the 
popup  menus  for  each  of  the  aircraft,  surface  ships  and  submarines  icons, 
countries  are  divided  into  geographic  regions.  After  the  selection  of  a  country, 
the  user  is  taken  to  another  menu  where  selection  of  an  agency,  within  the 
country  selected,  that  has  control  of  the  original  type  platforms  selected  (i.e. 
aircraft)  can  be  made.  As  shown  in  Figure  4,  after  the  selection  of  the  particular 
agency,  i.e.  “USN”  under  the  Aircraft  main  menu  icon,  the  screen  changes  to 
display  the  departments,  or  squadrons,  within  the  agency.  The  user  then  has 
access  to  the  individual  aircraft  type  within  the  department  or  squadron 
designation. 
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Figure  4  Department/Agency  Screen 


C.  AIRCRAFT.  SURFACE  SHIPS  AND  SUBMARINES  CARDS 

After  a  specific  aircraft,  surface  ship  or  submarine  is  chosen  the  user  is  then 
shown  the  card  with  that  specific  platform.  An  example  of  an  aircraft  card  is 
shown  in  Figure  5. 
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Figure  5  Aircraft  Data  Card 


On  the  card,  features  that  will  be  of  assistance  to  the  user  are  divided  into 
four  warfare  areas.  These  areas  are  anti-air  warfare  (AAW),  anti-surface 
warfare  (ASUW),  anti-submarine  warfare  (ASW),  and  electronic  warfare  (EW). 
There  are  many  other  warfare  areas,  however,  since  this  is  a  prototype 
application,  only  four  were  chosen  to  demonstrate  the  concept.  Repetition  of  the 
equipment  that  appear  under  these  menus  is  purposely  done  to  show  the 
possibilities  of  using  a  certain  system  across  warfare  areas.  An  example  of  this  is 
a  surface  to  air  missile  that  may  also  be  used  in  a  surface  to  surface  mode.  After 
a  system  is  selected  from  the  menu  of  a  warfare  area,  a  window  appears  (Figure 
6)  that  contains  specific  data  and  characteristics  that  a  TAO  may  require  for 
tactical  evaluation.  To  close  the  window,  simply  click  on  the  window  with  the 
cursor. 
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Figure  6  Information  Window 


D.  SEARCH  AND  IDENTIFY  FUNCTION 

One  of  the  most  useful  functions  that  is  available  to  a  TAO  in  the  Threat 
Evaluator  application  is  the  Search  and  Identify  option.  This  option  is  vital  for 
the  quick  identiHcation  of  possible  threats  associated  with  a  particular  emitter  or 
weapons  systems.  The  screen  for  the  Search  and  Identify  screen  is  shown  in 
Figure  7. 
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Figure  7  Search  and  Identify  Screen 


The  search  function  is  designed  to  accept  as  input  the  name  of  a  radar  or 
weapon  system  that  has  been  identified.  With  this  information  the  search 
algorithm  will  search  each  platform  card  for  a  match  to  the  system  entered  by 
the  user.  Upon  a  match,  the  names  of  platforms  which  have  that  emitter  or 
weapon  system  will  be  displayed  in  a  window  for  the  TAO  to  view.  If  the  TAO 
desires  further  information  on  a  particular  platform  that  has  been  identified  in 
the  list,  he  or  she  merely  uses  the  mouse  to  click  on  the  desired  platform’s  name 
and  the  information  card  of  that  platform  will  be  displayed.  The  TAO  can  then 
evaluate  in  detail  the  capabilities  of  the  platform  by  selecting  the  appropriate 
warfare  area  as  described  earlier  in  the  Aircraft,  Surface  Ships  and  Submarines 
Card  section. 


E.  TAO  STATUS  BOARD 

The  TAO  status  board  is  accessed  through  the  main  menu  screen  and  is  an 
exceptional  tool  available  to  the  TAO.  It  is  ideal  for  easy  access  to  all  required 
perishable  own  ships’  information.  This  portion  of  the  Threat  Evaluator 
provides  routinely  needed  data  to  the  TAO  and  provides  continuity  in  watch  to 
watch  turnovers.  The  TAO  status  board  is  comprised  of  two  cards  that  display 
critical  ships  information.  The  combination  of  these  two  cards  ensures  that  the 
TAO  has  available  at  his  fingertips  all  essential  data  for  fighting  the  ship. 

The  first  card  of  the  TAO  status  board  displays  tactical  weapons  systems’ 
information.  This  card  is  shown  in  Figure  8.  Weapons  status  and  the  condition 


Figure  8  TAO  Status  Board  Screen 
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of  readiness  that  the  ship  is  in  are  displayed  at  the  top  of  the  screen.  Changes  to 
these  are  accomplished  by  clicking  the  cursor  on  the  desired  button.  The  rest  of 
the  screen  is  divided  into  three  main  segments. 

The  segment  on  the  left  of  the  screen  contains  ASW  data  and  information  on 
the  specific  ASW  weapons  systems  of  the  ship.  Information  such  as  the  search 
mode  of  the  sonar,  water  conditions  for  the  day  and  torpedo  loading  data  are 
input  by  typing  the  information  in  the  spaces  provided  or  by  clicking  on  the 
appropriate  buttons. 

The  segment  on  the  right  of  the  screen  contains  information  on  the  gun 
systems  aboard  the  ship.  The  information  such  as  number  of  rounds  and  the 
status  of  the  chaff  can  be  changed  by  typing  the  information  into  the  spaces 
available  or  by  clicking  on  the  desired  buttons. 

The  segment  on  the  lower  center  of  the  screen  shows  the  remaining  missiles 
and  their  locations  in  the  magazine.  This  information  is  required  to  provide  the 
TAO  a  current  missile  magazine  inventory  update.  The  button  shown  in  Figure 
9,  will  take  the  user  to  the  second  screen  of  the  TAO  status  board. 


Figure  9  Combat  Systems/Engineering  Icon 

The  second  screen  of  the  TAO  status  board  is  divided  into  two  sections.  The 
left  section  on  the  screen  is  the  combat  systems  status  and  the  section  on  the  right 
of  the  screen  is  the  engineering  status.  The  material  condition  of  these  two  areas 
can  effect  the  combat  readiness  and  therefore  the  survivability  of  a  ship  in 
combat.  If  there  is  any  degradation  in  the  equipment,  then  the  TAO  must  be 
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aware  of  what  is  not  working  and  what  effect  its*  failure  has  on  the  combat 
readiness  of  the  ship.  Information  such  as  this  is  input  by  typing  the  information 
into  the  appropriately  labelled  spaces  available  or  by  clicking  on  the  desired 
buttons.  The  Combat  Systems  and  Engineering  status  screen  is  shown  in  Figure 
10. 
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Figure  10  Combat  Systems/Engineering  Screen 


F.  TACTICAL  ALGORITHMS 

Tactical  Algorithms  are  accessed  through  the  main  menu  screen.  This  is  a 
module  that  would  greatly  assist  the  TAO  in  weapons  selection  and  employment. 
Tactical  Algorithms  would  provide  the  user  with  a  method  of  quickly  calculating 
the  probability  of  a  kill  against  a  particular  target  with  a  selected  ship’s  weapon. 
This  would  then  aid  the  TAO  in  determining  the  optimum  weapon  mix  and 
release  point  against  the  target. 
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G.  EASY  ACCESS  BUTTONS 

Throughout  the  Threat  Evaluator,  the  TAO  has  access  to  a  number  of 
buttons.  These  buttons  provide  access  to  certain  modules  and  functions  which 
include  Battle  Orders,  Rules  of  Engagement,  Night  Orders,  TAO  Pass  Down 
Log,  INCSEA  signals.  Allied  Tactical  Publication  signals.  Find  function.  Help 
stack.  Home  stack  access.  Return,  Print,  and  Return  to  Main  Menu  commands. 
These  features  are  described  in  detail  in  the  following  sections. 

1.  Battle  Orders 

The  Commanding  Officer’s  battle  orders  are  contained  in  this  section. 
Access  to  them  is  achieved  by  clicking  on  the  icon  shown  in  Figure  1 1.  Within 
the  screen  is  an  icon  that  will  give  a  time  and  date  stamp  if  required.  This  icon  is 
shown  in  Figure  12. 


Figure  1 1  Battle  Orders  Icon 


Figure  12  Time/Date  Stamp  Icon 


49 


2.  Rules  of  Engagement  (ROE) 

The  Rules  of  Engagement  are  contained  in  this  section.  Access  to  them 
is  achieved  by  clicking  on  the  icon  shown  in  Figure  13.  A  time  and  date  stamp 
function  is  also  avaiable  on  this  screen. 


Figure  13  Rules  of  Engagement  Icon 

3.  Night  Orders 

The  Commanding  Officer’s  night  orders  are  contained  in  this  section. 
Access  to  them  is  achieved  by  clicking  on  the  icon  shown  in  Figure  14.  A  time 
and  date  stamp  function  is  also  avaiable  on  this  screen. 


Figure  14  Night  Orders  Icon 

4.  TAO  Pass  Down  Log  (PDL) 

The  TAO  Pass  Down  Log  is  contained  in  this  section.  Access  to  it  is 
achieved  by  clicking  on  the  icon  shown  in  Figure  15.  A  time  and  date  stamp 
function  is  also  avaiable  on  this  screen. 
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Figure  15  TAO  Pass  Down  Log  Icon 


5.  INCSEA 

The  INCSEA  signals  will  be  accessed  through  the  icon  shown  in  Figure 
16.  The  module  would  contain  all  the  signals  from  the  agreement.  These  signals 
would  be  displayed  either  in  a  list  or  a  specific  signal  could  be  decoded  as 
desired.  The  signal  would  be  input  by  the  TAO,  resulting  in  the  decoded 
meaning  being  displayed  on  the  screen.  This  would  give  the  TAO  quick  access  to 
required  information.  As  envisioned,  signals  could  also  be  encoded  using  this 
system  tool. 


Figure  16  INCSEA  Incon 


6.  Allied  Tactical  Publication  (ATP) 

The  ATP- 1(C)  signals  will  be  accessed  through  the  icon  shown  in 
Figure  17.  The  module  would  contain  all  the  signals  from  the  ATP- 1(C)  as  well 
as  the  information  describing  general  maneuvers..  These  signals  would  be 
displayed  either  in  a  list  or  a  specific  signal  could  be  decoded  as  desired.  The 
signal  would  be  input  by  the  TAO,  resulting  in  the  decoded  meaning  being 
displayed  on  the  screen.  This  would  give  the  TAO  quick  access  to  required 
information.  As  envisioned,  signals  could  also  be  encoded  using  this  system  tool. 
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HELP 


Figure  19  Help  Stack  Icon 


9.  Home  Stack 

The  Home  stack  will  be  accessed  through  the  icon  shown  in  Figure  20. 
This  takes  the  user  to  the  home  card  of  the  HyperCard  environment. 


Figure  20  Home  Card  Icon 


10.  Return 

The  Return  command  will  be  accessed  through  the  icon  shown  in  Figure 
21.  This  button  returns  the  user  to  the  previous  screen. 


Figure  21  The  Return  Icon 


11.  Print 

The  Print  command  will  be  accessed  through  the  icon  shown  in  Figure 
22.  This  allows  the  user  to  print  items  if  required. 
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Figure  22  The  Print  Icon 

12.  Return  to  Main  Menu  Button 

The  Return  to  Main  Menu  button  will  be  accessed  through  the  icon 
shown  in  Figure  23.  This  allows  the  user  to  return  to  the  main  menu  screen  fron 
any  location  in  the  Threat  Evaluator.  This  gives  easy  access  to  the  main  menu  by 
a  single  click  on  the  mouse. 


Figure  23  The  Return  to  Main  Menu  Button 
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